Security Objects Controlling Access To Resources

ABSTRACT

Controlling access to resources through use of security objects including creating a security object in dependence upon user-selected security control data types, the security object comprising security control data and at least one security method; receiving a request for access to the resource; receiving security request data; and determining access to the resource in dependence upon the security control data and the security request data. Creating a security object includes storing in the security object a resource identification for the resource; storing in the security object an authorization level of access for the resource; storing in the security object user-selected security control data types; and storing in the security object security control data for each user-selected security control data type. Embodiments include deploying the security object on a security server or on a client device.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation application of and claims priorityfrom U.S. patent application Ser. No. 10/179,328, filed on Jun. 24,2002.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to data processing methods, apparatus,systems, and computer program products therefore, and more particularlyto methods, apparatus, systems, and computer program products in supportof securing valid authentication and authorization for access tocomputer resources and other items.

2. Description of Related Art

It is common to use passwords to control access to resources, includingeverything from documents, to bank accounts, burglar alarms,automobiles, home security systems, personal video recorders, and so on.Passwords often consist of text strings that a user must provide to asecurity system in order to obtain access to a secured resource. Apassword provided by a user typically is checked against a storedpassword to determine a match. If the entered password and the storedpassword match, access is granted to the resource.

Mechanisms for managing passwords typically are programmed into thesoftware applications with which the passwords are associated. That is,a program external to the password is used to authenticate the password,check to see if the password is about to expire, and determine theaccess granted. Systems securing resources therefore typically havepassword management operations coded into them to process andauthenticate a specific type of password content. Users have no controlover how passwords are defined or used in typical systems securingresources. Moreover, changing the way in which a password is usedtypically requires changing program code in a system securing resources.

In addition, such systems generally are capable of accepting andadministering security with respect only one type of password. Ifpasswords are viewed as one type of security control data, then suchsystems can be said to function with only one kind of security controldata. There is no way in such systems for anyone, especially not a user,to change from a password to some other kind of security control datawithout substantial redesign and recoding. There is no way in suchsystem for a user or anyone else to determine to use more than one kindof security control data without substantial redesign and recoding. Itwould be beneficial to have improved ways of choosing and using securitycontrol data to secure resources through computer systems.

SUMMARY OF THE INVENTION

Various exemplary embodiments of the invention are described as methods,systems, and products for controlling access to a resource includingcreating a security object in dependence upon user-selected securitycontrol data types, the security object comprising security control dataand at least one security method; receiving a request for access to theresource; receiving security request data; and determining access to theresource in dependence upon the security control data and the securityrequest data. Creating a security object typically includes storing inthe security object a resource identification for the resource; storingin the security object an authorization level of access for theresource; storing in the security object user-selected security controldata types; and storing, in the security object, security control datafor each user-selected security control data type. Methods according tothe present invention typically include deploying the security object ona security server or on a client device.

In some embodiment of the present invention, the resource resides on aresource server, an embodiment includes deploying the security object ona security server, and receiving a request for access to a resourcefurther comprises receiving the request for access to the resource in asecurity server from a client device across a network. In otherembodiments, the resource resides on a client device, the client devicehas an application program, the method further comprises deploying thesecurity object on the client device, and receiving a request for accessto the resource further comprises receiving the request for access tothe resource in the security object itself as a call to the securitymethod.

In typical embodiments, determining access includes authorizing a levelof access in dependence upon the authorization level of access for theresource. In many embodiments, receiving a request for access to aresource includes calling a security method in a security object.Receiving a request for access to a resource typically includesidentifying a security object controlling access to the resource. Insome embodiments, identifying the security object comprises identifyingthe security object in dependence upon a Universal Resource Identifier(“URI”). In some embodiments, identifying the security object comprisesidentifying the security object in dependence upon a URI that identifiesthe resource, including finding, in dependence upon the URI identifyingthe resource, an identification of the security object in an accesscontrol table.

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescriptions of exemplary embodiments of the invention as illustrated inthe accompanying drawings wherein like reference numbers generallyrepresent like parts of exemplary embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 a, 1 b, and 1 c set forth block diagrams depicting alternativeexemplary data processing architectures useful in various embodiments ofthe present invention.

FIG. 2 sets forth a data flow diagram depicting exemplary methods ofcontrolling access to a resource, including creating a security objectand receiving a request for access to a resource, and determiningwhether to grant access to the resource.

FIG. 3 sets forth a data flow diagram depicting an exemplary method ofcreating a security object.

FIG. 4 sets forth a class relations diagram including a security classand a security control class.

FIG. 5 sets forth a data flow diagram depicting exemplary methods ofreceiving requests for access to resources.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS Introduction

The present invention is described to a large extent in thisspecification in terms of methods for securing valid authentication andauthorization for access to computer resources and other items. Personsskilled in the art, however, will recognize that any computer systemthat includes suitable programming means for operating in accordancewith the disclosed methods also falls well within the scope of thepresent invention.

Suitable programming means include any means for directing a computersystem to execute the steps of the method of the invention, includingfor example, systems comprised of processing units and arithmetic-logiccircuits coupled to computer memory, which systems have the capabilityof storing in computer memory, which computer memory includes electroniccircuits configured to store data and program instructions, programmedsteps of the method of the invention for execution by a processing unit.The invention also may be embodied in a computer program product andstored on a diskette or other recording medium for use with any suitabledata processing system.

Embodiments of a computer program product may be implemented by use ofany recording medium for machine-readable information, includingmagnetic media, optical media, or other suitable media. Persons skilledin the art will immediately recognize that any computer system havingsuitable programming means will be capable of executing the steps of themethod of the invention as embodied in a program product. Personsskilled in the art will recognize immediately that, although most of theexemplary embodiments described in this specification are oriented tosoftware installed and executing on computer hardware, nevertheless,alternative embodiments implemented as firmware or as hardware are wellwithin the scope of the present invention.

DEFINITIONS

In this specification, the terms “field,” “data element,” and“attribute,” unless the context indicates otherwise, generally are usedas synonyms, referring to individual elements of digital data.Aggregates of data elements are referred to as “records” or “datastructures.” Aggregates of records are referred to as “tables” or“files.” Aggregates of files or tables are referred to as “databases.”Complex data structures that include member methods, functions, orsoftware routines as well as data elements are referred to as “classes.”Instances of classes are referred to as “objects” or “class objects.”

“Browser” means a web browser, a communications application for locatingand displaying web pages. Browsers typically comprise a markup languageinterpreter, web page display routines, and an HTTP communicationsclient. Typical browsers today can display text, graphics, audio andvideo. Browsers are operative in web-enabled devices, including wirelessweb-enabled devices. Browsers in wireless web-enabled devices often aredownsized browsers called “microbrowsers.” Microbrowsers in wirelessweb-enabled devices often support markup languages other than HTML,including for example, WML, the Wireless Markup Language.

“CORBA” means the Common Object Request Broker Architecture, a standardfor remote procedure invocation first published by the Object ManagementGroup (“OMG”) in 1991. CORBA can be considered a kind of object-orientedway of making “RPCs” or remote procedure calls, although CORBA supportsmany features that do not exist in RPC as such. CORBA uses a declarativelanguage, the Interface Definition Language (“IDL”), to describe anobject's interface. Interface descriptions in IDL are compiled togenerate ‘stubs’ for the client side and ‘skeletons’ on the server side.Using this generated code, remote method invocations effected inobject-oriented programming languages such as C++ and Java look likeinvocations of local member methods in local objects. Whenever a clientprogram, such as, for example, a C++ program, acquires an objectreference, decoded from a stringified object reference, from a NamingService, or as a result from another method invocation, an ORB creates astub object. Since a stub object cannot exist without an objectreference, and an object reference rarely exists outside a stub object,these two terms are often used synonymously. For the server side, askeleton is generated by the IDL compiler. A developer derives from thatskeleton and adds implementation; an object instance of such animplementation class is called a ‘servant.’ The generated skeletonreceives requests from the ORB, unmarshalls communicated parameters andother data, and performs upcalls into the developer-provided code. Thisway, the object implementation also looks like a ‘normal’ class.

“CGI” means “Common Gateway Interface,” a standard technology for datacommunications of resources between web servers and web clients. Morespecifically, CGI provides a standard interface between servers andserver-side ‘gateway’ programs which administer actual reads and writesof data to and from file systems and databases. The CGI interfacetypically sends data to gateway programs through environment variablesor as data to be read by the gateway programs through their standardinputs. Gateway programs typically return data through standard output.

“Client device” refers to any device, any automated computing machinery,capable of requesting access to a resource. Examples of client devicesare personal computers, internet-enabled special purpose devices,internet-capable personal digital assistants, wireless handheld devicesof all kinds, garage door openers, home security computers, thumbprintlocks on briefcases, web-enabled devices generally, and handheld devicesincluding telephones, laptop computers, handheld radios, and others thatwill occur to those of skill in the art. Various embodiments of clientdevices are capable of asserting requests for access to resources viawired and/or wireless couplings for data communications. The use as aclient device of any instrument capable of a request for access to aresource is well within the present invention.

A “communications application” is any data communications softwarecapable of operating couplings for data communications, including emailclients, browsers, special purpose data communications systems, as wellas any client application capable of accepting data downloads (downloadsof security objects or resources, for example) via hardwiredcommunications channels such as, for example, a Universal Serial Bus or‘USB,’ downloads through wired or wireless networks, and downloadsthrough other means as will occur to those of skill in the art. Intypical embodiments of the present invention, communicationsapplications run on client devices.

“DCOM” means ‘Distributed Component Object Model,’ an extension ofMicrosoft's Component Object Model (“COM”) to support objectsdistributed across networks. DCOM is part of certain Microsoft operatingsystems, including Windows NT, and is available for other operatingsystems. DCOM serves the same purpose as IBM's DSOM protocol, which is apopular implementation of CORBA. Unlike CORBA, which runs on manyoperating systems, DCOM is currently implemented only for Windows.

“HTML” stands for ‘HyperText Markup Language,’ a standard markuplanguage for displaying web pages on browsers.

“HTTP” stands for ‘HyperText Transport Protocol,’ the standard datacommunications protocol of the World Wide Web.

A “hyperlink,” also referred to as “link” or “web link,” is a referenceto a resource name or network address which when invoked allows thenamed resource or network address to be accessed. More particularly interms of the present invention, invoking a hyperlink implements arequest for access to a resource. Often a hyperlink identifies a networkaddress at which is stored a resource such as a web page or otherdocument. As used here, “hyperlink” is a broader term than “HTML anchorelement.” Hyperlinks include links effected through anchors as well asURIs invoked through ‘back’ buttons on browsers, which do not involveanchors. Hyperlinks include URIs typed into address fields on browsersand invoked by a ‘Go’ button, also not involving anchors. In addition,although there is a natural tendency to think of hyperlinks asretrieving web pages, their use is broader than that. In fact,hyperlinks access “resources” generally available through hyperlinksincluding not only web pages but many other kinds of data andserver-side script output, servlet output, CGI output, and so on.

“LAN” means local area network.

“Network” is used in this specification to mean any networked couplingfor data communications among computers or computer systems. Examples ofnetworks useful with the invention include intranets, extranets,internets, local area networks, wide area networks, and other networkarrangements as will occur to those of skill in the art.

An “ORB” is a CORBA Object Request Broker.

“Resource” means any information or physical item access to which iscontrolled by security objects of the present invention. Resources oftencomprise information in a form capable of being identified by a URI orURL. In fact, the ‘R’ in ‘URI’ is ‘Resource.’ The most common kind ofresource is a file, but resources include dynamically-generated queryresults, the output of CGI scripts, dynamic server pages, documentsavailable in several languages, as well as physical objects such asgarage doors, briefcases, and so on. It may sometimes be useful to thinkof a resource as similar to a file, but more general in nature. Files asresources include web pages, graphic image files, video clip files,audio clip files, and so on. As a practical matter, most HTTP resourcesare currently either files or server-side script output. Server sidescript output includes output from CGI programs, Java servlets, ActiveServer Pages, Java Server Pages, and so on.

“RMI,” or “Java RMI,” means ‘Remote Method Invocation,’ referring to aset of protocols that enable Java objects to communicate remotely withother Java objects. RMI's structure and operation is somewhat likeCORBA'S, with stubs and skeletons, and references to remotely locatedobjects. In comparison with other remote invocations protocols such asCORBA and DCOM, however, RMI is relatively simple. RMI, however, worksonly with Java objects, while CORBA and DCOM are designed to supportobjects created in any language.

“Server” in this specification refers to a computer or device comprisingautomated computing machinery on a network that manages resources andrequests for access to resources. A “security server” can be any serverthat manages access to resources by use of security objects according tothe present invention. A “web server,” or “HTTP server,” in particularis a server that communicates with browsers by means of HTTP in order tomanage and make available to networked computers documents in markuplanguages like HTML, digital objects, and other resources.

A “Servlet,” like an applet, is a program designed to be run fromanother program rather than directly from an operating system.“Servlets” in particular are designed to be run on servers from aconventional Java interface for servlets. Servlets are modules thatextend request/response oriented servers, such as Java-enabled webservers. Java servlets are an alternative to CGI programs. The biggestdifference between the two is that a Java servlet is persistent. Once aservlet is started, it stays in memory and can fulfill multiplerequests. In contrast, a CGI program disappears after it has executedonce, fulfilling only a single a request for each load and run. Thepersistence of Java servlets makes them generally faster than CGIbecause no time is spent on loading servlets for invocations after afirst one.

A “URI” or “Universal Resource Identifier” is an identifier of a namedobject in any namespace accessible through a network. URIs arefunctional for any access scheme, including for example, the FileTransfer Protocol or “FTP,” Gopher, and the web. A URI as used intypical embodiments of the present invention usually includes aninternet protocol address, or a domain name that resolves to an internetprotocol address, identifying a location where a resource, particularlya web page, a CGI script, or a servlet, is located on a network, usuallythe Internet. URIs directed to particular resources, such as particularHTML files or servlets, typically include a path name or file namelocating and identifying a particular resource in a file system coupledthrough a server to a network. To the extent that a particular resource,such as a CGI file or a servlet, is executable, for example to store orretrieve data, a URI often includes query parameters, or data to bestored, in the form of data encoded into the URI. Such parameters ordata to be stored are referred to as ‘URI encoded data.’ “URLs” or“Universal Resource Locators” comprise a kind of subset of URIs, whereineach URL resolves to a network address. That is, URIs and URLs aredistinguished in that URIs identify named objects in namespaces, wherethe names may or may not resolve to addresses, while URLs do resolve toaddresses. Although standards today are written on the basis of URIs, itis still common to such see web-related identifiers, of the kind used toassociate web data locations with network addresses for datacommunications, referred to as “URLs.” This specification refers to suchidentifiers generally as URIs.

“WAN” means ‘wide area network.’ One example of a WAN is the Internet.

“World Wide Web,” or more simply “the web,” refers to a system ofinternet protocol (“IP”) servers that support specially formatteddocuments, documents formatted in markup languages such as HTML, XML(eXtensible Markup Language), WML (Wireless Markup Language), or HDML(Handheld Device Markup Language). The term “Web” is used in thisspecification also to refer to any server or connected group orinterconnected groups of servers that implement a hyperlinking protocol,such as HTTP or WAP (the ‘Wireless Access Protocol’), in support of URIsand documents in markup languages, regardless of whether such servers orgroups of servers are coupled to the World Wide Web as such.

DETAILED DESCRIPTION

Embodiments of the present invention provide security objects forimproving the administration of controlling access to secured resources.FIGS. 1 a, 1 b, and 1 c set forth block diagrams depicting alternativeexemplary data processing architectures useful in various embodiments ofthe present invention.

As illustrated in FIG. 1 a, some embodiments of the present inventiondeploy security objects (108) in security servers (106) coupled for datacommunications through LANs (116) to resource servers (110) upon whichresources (112) are stored. Such embodiments typically are coupled fordata communications to client devices (102) through networks such asWANs (114) or LANs (116). Data communications between client devices andsecurity servers in such architectures are typically administered bycommunications applications (104), including, for example, browsers.WANs include internets and in particular the World Wide Web. Clientdevices (102) are defined in detail above and include any automatedcomputing machinery capable of accepting user inputs through a userinterface and carrying out data communications with a security server. A“security server” is any server that manages access to resources by useof security objects according to the present invention.

As illustrated in FIG. 1 b, some embodiments of the present inventiondeploy security objects (108) in security servers (106) upon which arestored secured resources (112). The architecture of FIG. 1 b illustratesthat resources can be stored on the same server that secures access tothe resources. In all this discussion, the term ‘security server’ refersto a server that manages access to resources by use of security objectsaccording to the present invention. There is no limitation that a‘security server’ as the term is used in this disclosure must provideother security services, or indeed that a security server must provideany security services whatsoever, other than managing access toresources through security objects. FIGS. 1 a and 1 b show securityobjects deployed in or upon security servers, but having securityobjects deployed upon it is not a requirement for a server to beconsidered a security server within the usage of this disclosure.Security objects may be deployed anywhere on a network or on clientdevices. If a server manages access to resources by use of securityobjects, regardless where the security objects are located, then thatserver is considered a ‘security server’ in the terminology of thisdisclosure. Some ‘security servers’ of the present invention, asdescribed in more detail below, are ordinary web servers modifiedsomewhat to support lookups in access control tables. Many ‘securityservers’ of the present invention, however, are ordinary unmodified webservers or Java web servers, designated as ‘security servers’ onlybecause they manage access to resources by use of security objects,security objects which may or may not be installed upon those sameservers.

As shown in FIG. 1 c, some embodiments deploy security objects (108) inclient devices (102) which themselves also contain both the applicationssoftware (120) concerned with accessing the resources and also theresources (112) themselves. This architecture includes devices in whicha security object may be created on a more powerful machine and thendownloaded to a less powerful machine. The less powerful machine thenoften is associated one-to-one with a single resource, or is used tosecure a relatively small number of resources. One example of this kindof embodiment includes a garage door opener in which a securityapplication program (120) is implemented as an assembly language programon a tiny microprocessor or microcontroller and the secured resource isa motor that operates a garage door. Another example is a briefcasefitted with a microprocessor or microcontroller, a fingerprint reader,and a USB port through which is downloaded a security object thatcontrols access to a resource, an electromechanical lock on thebriefcase.

FIG. 2 sets forth a data flow diagram depicting an exemplary method ofcontrolling access to a resource (112). The method of FIG. 2 includescreating (206) a security object (108) in dependence upon user-selectedsecurity control data types (204), the security object comprisingsecurity control data (216). In this disclosure, the applicationprograms that administer the creation of security objects are called‘foundries.’ In typical embodiments according to FIG. 2, a foundry (224)prompts a user through a user interface displayed on a client device(102) to select one or more security control data types through, forexample, use of a menu similar to this one:

-   -   Please select a security control data type:        -   1. User Logon ID        -   2. Password        -   3. Fingerprint        -   4. Voice Recognition        -   5. Retinal Scan    -   Your selection (1-5): ______

The foundry (224) creates (206) the security object (108) in dependenceupon the user's selections of security control data types in the sensethat the foundry aggregates into, or associates by reference, thesecurity object security control data types according to the user'sselection. If, for example, the user selects menu item 1 for a userlogon ID, the foundry causes a security control data type to be includedin the security object for administration of a user logon ID. If theuser selects menu item 2 for a password, the foundry causes a securitycontrol data type to be included in the security object foradministration of a password. If the user selects menu item 3 for afingerprint, the foundry causes a security control data type to beincluded in the security object for administration of fingerprints. Andso on for voice recognition technology, retinal scans, and any otherkind of security control data amenable to administration by electronicdigital computers.

In typical embodiments of the present invention, as shown in FIG. 2, asecurity object (108) includes at least one security method (218). Inthis disclosure, ‘security method’ means an object oriented membermethod. The security method typically is a software routine called forvalidating or determining whether to grant access to a resource and whatlevel of authorization to grant. As discussed in more detail below, thesecurity method can have various names depending on how the securityobject is implemented, ‘main( )’ for security objects to be invoked withJava commands, ‘security( )’ for servlets, and so on. These exemplarynames are for clarity of explanation only, not for limitation. In manyforms of security object, the name chosen for the security method is ofno concern whatsoever.

Embodiments according to FIG. 2 include receiving (208) a request (210)for access to the resource and receiving a request for access to aresource can be implemented as a call to a security method in a securityobject. A security object implemented in Java, for example, can have amain( ) method called by invocation of the security object itself, as incalling ‘java MySecurityObject,’ resulting in a call toMySecurityObject.main( ). This call to main( ) is in many embodimentsitself receipt of a request for access to the resource secured by use ofthe security object.

The method of FIG. 2 includes receiving (212) security request data(214). Continuing with the example of a security object called‘MySecurityObject,’ the security object's member security method canprompt the user, or cause the user to be prompted, for security requestdata in dependence upon the security control data types in use in thesecurity object. That is, if the security object contains securitycontrol data of type ‘User Logon ID,’ then the security method causesthe user to be prompted to enter security request data, expecting thesecurity request data received to be a user logon ID. If the securityobject contains security control data of type ‘Password,’ then thesecurity method causes the user to be prompted to enter security requestdata, expecting the security request data received to be a password. Ifthe security object contains security control data of type‘Fingerprint,’ then the security method causes the user to be promptedto enter security request data, expecting the security request datareceived to be a digital representation of a fingerprint. The securitymethod in such embodiments typically does not include in its prompt tothe user any identification of the security control data type expected.This is, after all, a security system. If the user does not know thatthe user must provide in response to a first prompt a password and inresponse to a second prompt a thumbprint in order to gain access to aparticular resource, then the user probably ought not gain access to theresource.

As described in more detail below, security objects typically associateby reference one or more security control objects having member methodsthat carry out actual security request data validation. Calls from asecurity object's security method to member methods in security controlobjects are what is meant by saying that a security method “causes” auser to be prompted for security request data.

The method of FIG. 2 includes determining (220) access (222) to theresource in dependence upon the security control data (216) and thesecurity request data (214). More particularly, determining access meansdetermining whether to grant access and what kind of access is to begranted. Generally in this disclosure, whether to grant access to aparticular user is referred to as ‘authentication,’ and the kind ofaccess granted is referred to as ‘authorization level.’ Determiningwhether to grant access typically includes determining whether securityaccess data provided by a user in connection with a request for accessto a resource matches corresponding security control data. That is, inthe example of a password, determining whether to grant access includesdetermining whether a password provided as security access data matchesa password stored in aggregation with a security object as securitycontrol data. In the example of a thumbprint, determining whether togrant access includes determining whether a thumbprint provided assecurity access data matches a thumbprint stored in aggregation with asecurity object as security control data. And so on. Authorizationlevels include authorization to read a resource, authorization to writeto a resource (which typically includes ‘edit’ authority and ‘delete’authority), and authorization to execute a resource (for which oneordinarily needs an executable resource).

FIG. 3 sets forth a data flow diagram depicting an exemplary method ofcreating a security object. In other words, the method depicted in FIG.3 drills down on what it means to create a security object in a foundryof the present invention. In the method of FIG. 3 creating a securityobject is shown to include storing (302) in the security object (108) aresource identification (312) for the resource. In other words, thefoundry prompts the user to enter a filename, pathname, URL, URI, or anyuseful means as will occur to those of skill in the art for identifyinga resource to be secured by the security object. In this example, thefoundry then stores (302) the identification of the resource in a memberfield called ‘resourceID’ (312) in the security object itself.

In the method of FIG. 3 creating a security object includes storing(304) in the security object (108) an authorization level (314) ofaccess for the resource. In other words, the foundry prompts the user toenter an authorization level, ‘read,’ ‘write,’ or ‘execute,’ forexample, and then stores (304) the authorization level in a member fieldnamed ‘authorizationLevel’ (314) in the security object itself.

In the method of FIG. 3, creating a security object includes storing(306) in the security object (108) user-selected security control datatypes (310). More particularly, in the method of FIG. 3, securitycontrol data types (310) are stored as references to security controlobjects (316). Security control data types (310) in fact are securitycontrol classes (404 on FIG. 4) from which security control objects areinstantiated. Storing (306) user-selected security control data typescomprises storing references to security control objects (316) in asecurity control object list (318) in the security object (108),including instantiating a security control object (316) of a securitycontrol class in dependence upon security control data type. That is, ifthe security control data type is a password, then the foundry causes tobe instantiated from a password security control class a passwordsecurity control object, storing in the security control object list(318) a reference to the password security control object. Similarly, ifthe security control data type is a fingerprint, then the foundry causesto be instantiated from a fingerprint security control class afingerprint security control object, storing in the security controlobject list (318) a reference to the fingerprint security controlobject. And so on.

The security control object list (318) itself is typically implementedas a container object from a standard library in, for example, C++ orJava. That is, the security control object list (318) is typically aclass object aggregated by reference to the security object (108).

In the method of FIG. 3, creating a security object includes storing(308) in the security object security control data (216) for eachuser-selected security control data type (310). Instantiating a securitycontrol object (316) calls a constructor for the security controlobject. In some embodiments, it is the constructor that prompts forsecurity control data of the type associated with the security controlobject. That is, if the security control data object is a passwordsecurity control object, its constructor prompts for a password to bestored (308) as security control data (216). Similarly, if the securitycontrol data object is a thumbprint security control object, itsconstructor prompts for a thumbprint to be stored (308) as securitycontrol data (216). And so on.

In architectures similar to those illustrated in FIG. 1 a and 1 b inwhich a client device (102) is located remotely across a network (114)from a security server (106) upon which security control data is to bestored (308), the security control data advantageously is communicatedacross the network from the client device to the security server inencrypted form. One example of such encrypted communications is networkmessaging by use of ‘SSL,’ that is, communications connections through a‘Secure Sockets Layer,’ a known security protocol for use in internetprotocol (“IP”) networks, in which encryption of message packets isprovided as a standard communications service. In addition to encryptedcommunications of security control data, at least some elements ofsecurity control data, such as, for example, passwords, also areadvantageously stored (308) in encrypted form.

Even more particularly, foundries according to the present invention maybe implemented and operated in accordance with the following pseudocode.

Class Foundry { private String selectionText = “Please select a securitycontrol data type: 1. Password 2. Fingerprint 3. Voice Recognition Yourselection (1-3):              ” void main( ) { // create security objectSecurityClass SO = new SecurityClass( ); // identify resource secured bythe new security object Resource resourceID = getResourceID(“Pleaseenter resource ID:        ”); // store resource ID in security objectSO.setResource(resourceID); // prompt for authorization level charauthorizationLevel = getAuthorizationLevel(“Please enter authorizationlevel:        ”); // store authorization level in security objectSO.setAuthorizationLevel(authorizationLevel); // get a first ‘SCD-Type,’Security Control Data Type SCD-Type = getUserSelection(selectionText);while(SCD-Type != null) { // based on SCD-Type, create Security ControlObject SCO = SCO-Factory.createSCO(SCD-Type); // store security controldata in the security control object SCO.setSecurityControlData( ); //add new SCO to the list in the Security Object SO.add(SCO); // getanother SCD-Type, as many as user wants SCD-Type =getUserSelection(selectionText); } // end while( ) } // end main( ) } //end Foundry

With reference to FIGS. 2 and 3, the pseudocode foundry creates (206) asecurity object (108) by instantiating a security class:

SecurityClass SO = new SecurityClass( ). The pseudocode foundry thenstores (302) a resource identification (312) through: ResourceresourceID = getResourceID(“Please enter resource ID:       ”);SO.setResource(resourceID); The call to SO.setResource( ) is a call to amember method in the security object described in more detail below. Thepseudocode foundry stores (304) an authorization level (314) through:char authorizationLevel = getAuthorizationLevel(“Please enterauthorization level:        ”);SO.setAuthorizationLevel(authorizationLevel); The call toSO.setAuthoriztionLevel( ) is a call to a member method in the securityobject described in more detail below.

The pseudocode foundry stores (306) security control data types (310) byrepeated calls to SO.add(SCO). SO.add( ) is a member method in thesecurity object that adds security control objects to a list in thesecurity object as described in more detail below.

The pseudocode foundry stores (308) security control data (216) in thesecurity object (108) by repeated calls to SCO.setSecurityControlData(). SCO.setSecurityControlData( ) is a member method in a securitycontrol object (316) that prompts for and stores a type of security datawith which the security control object is associated, fingerprints forfingerprint security control object, passwords for password securitycontrol objects, and so on. A separate security control object iscreated for each security control data type selected or request by theuser in response to getUserSelection(selectionText).

Each time the user selects a new security control data type, the foundrycreates a new security control object by calling a factory method in asecurity control object factory. The security control object factory isa class called SCO-Factory, and the factory method isSCO-Factory.createSCO( ). The calls to SCO.setSecurityControlData( ) arepolymorphic calls, each of which typically accesses a different securitycontrol object although exactly the same line of code is used for eachsuch call. In this elegant solution, the foundry itself never knows orcares which security control data types are implemented or what securitycontrol data is stored in security objects it creates.

Readers of skill in the art may notice that the foundry could be madeeven leaner by allowing security control object constructors to carryout the work of SCO.setSecurityControlData( ). In this example, however,for clarity of explanation of the operation of the foundry,SCO.setSecurityControlData( ) is left at the foundry level so that theeffects of foundry operations are more fully exposed by the foundryitself.

The process of creating security control objects can be carried out asillustrated in the following pseudocode factory class:

// // Security Control Object Factory Class // // Defines aparameterized factory method for creating security control objects //class SCO-Factory { public static SecurityControlClasscreateSCO(SCD-Type) { // establish null reference to new SecurityControl Object SecurityControlClass SecurityControlObject = null;switch(SCD-Type) { case LOGONID: SecurityControlObject = newLogonIDSecurityControlClass; break; case PASSWORD: SecurityControlObject= new PasswordSecurityControlClass; break; ... ... ... // Can have manysecurity control data types, // not merely these four case FINGERPRINT:SecurityControlObject = new FingerprintSecurityControlClass; break; caseRETINA: SecurityControlObject = new RetinaSecurityControlClass; break; }// end switch( ) return SecurityControlObject; } // end createSCO ( ) }// end class SCO-Factory

The factory class implements the createSCO( ) method, which is aso-called parameterized factory method. CreateSCO( ) accepts as aparameter the security control data type ‘SCD-Type’ of the securitycontrol data to be administered by a security control object. CreateSCO() then operates a switch( ) statement in dependence upon SCD-Type todecide exactly which security control class to instantiate depending onwhich type of security control data is needed—logon IDs, passwords,fingerprints, voice identifications, and so on. Although only foursecurity control data types are illustrated in the factory class (logonIDs, passwords, fingerprints, and retinal scans), in fact the factorycan create and return to the calling foundry a security control objectfor any type of security control data supported by the security systemin which it is installed, that is, any type of security control objectfor which a security control data type or class (404) is defined.

Security control objects can be instantiated from a security controlclass according to the following pseudocode security control class:

// // abstract SecurityControlClass // Abstract ClassSecurityControlClass { private String SecurityControlData; public voidsetSecurityControlData( ) { SecurityControlData = prompt( “Please entersecurity control data:            ); } public boolean validate( ) {SecurityAccessData = prompt(“Enter Security Access Data:                        ”); if(SecurityControlData ==SecurityAccessData) return true; else return false; } }

The pseudocode security control class depicts an object oriented‘interface.’ In Java, such structures are literally known as‘interfaces’ to be ‘extended’ by concrete classes. In C++, suchstructures are known as abstract base classes from which concretesubclasses inherit. Either way, the pseudocode security control classestablishes a set of public member methods to be used by all securitycontrol objects. The pseudocode security control class provides stringstorage of security control data, which may work just fine for logon IDsand passwords, but will not work for fingerprints and voice recognition.Similarly, setSecurityControlDate( ) and validates will be implementeddifferently for different types of security control data.

The member fields and member methods of the pseudocode security controlclass form an interface that is fully expected to be overridden insubclasses from which security control objects are instantiated,although all subclasses are required to implement in some fashion thepublic member fields and public member methods of the abstract baseclass, the security control class. Here, beginning with a concretesecurity control class for logon IDs, are several examples of concretesecurity control classes from which practical security control objectsare instantiated by the factory method SecurityControlClass.createSCO().

// // concrete security control class for logon IDs // ClassLogonIDSecurityControlClass : SecurityControlClass { private StringSecurityControlData; public void setSecurityControlData( ) {SecurityControlData = prompt( “Please enter security control data:          ); } public boolean validate( ) { SecurityAccessData =prompt(“Enter Security Access Data:                         ”);if(SecurityControlData == SecurityAccessData) return true; else returnfalse; } }

The LogonIDSecurityControlClass appears almost identical to its parentSecurityControlClass, but it is important to remember thatLogonIDSecurityControlClass, unlike its abstract parent, defines a classthat can actually be instantiated as a security control object fordetermining access to resources on the basis of entry of a valid logonID. The following pseudocode security control class for fingerprintsillustrates how security control classes differ across security controldata types.

// // concrete security control class for fingerprints // ClassFingerprintSecurityControlClass : SecurityControlClass { private FileSecurityControlData; public void setSecurityControlData( ) {SecurityControlData = prompt( “Please enter security control data:          ); } public boolean validate( ) { FILE SecurityAccessData =prompt(“Enter Security Access Data:                         ”);if((bitwiseCompare(SecurityControlData, SecurityAccessData))!=true)return true; else return false; } }

In FingerprintSecurityControlClass, SecurityControlData is in a filerather than a string. Similarly, the prompt( ) function in the validatesmethod expects the user to provide a fingerprint file in response to theprompt for security control data. In addition, the bitwiseCompare( )method, although not shown, is implemented to open both files, comparethem bit by bit, and ultimately deny access to a resource if thecomparison fails.

Security objects themselves can be implemented, for example, accordingto the following pseudocode security class.

// // SecurityClass ... // a class from which security objects can beinstantiated // Class SecurityClass { private Resource aResourceID;public void setResourceID(resourceID) { aResourceID = resourceID } charanAuthorizationLevel; public voidsetAuthorizationLevel(authorizationLevel) { anAuthorizationLevel =authorizationLevel } // list of security control objects (references,actually) private List aList = new List( ); // method for addingSecurity Control Objects to the List public void add(SCO) {aList.add(SCO); } // validate requests for access against all SCOs inthe list public boolean main( ) { SCO = aList.getFirst( ); while(SCO !=null) { if((SCO.validate( )) != true) { denyAccess( ); return false; }SCO = aList.getNext( ); } // all SCOs in the List are now validatedgrantAccess(anAuthorizationLevel); return true; } // end validate( ) }// end SecurityClass

The security class provides a storage location for a resourceidentification (312) named ‘resource ID,’ as well a member method namedsetResourceID( ) for storing (302) the resource identification.Similarly, the security class provides a field for authorization leveland a method for storing (304) authorization level. The exemplarypseudocode security class provides storage in the form of a list forstoring security control objects. In C++, it would be possible to storesecurity control objects as such, but in typical embodiments, the listis used to store security control objects as references.

The security class includes a method, addSCO( ) for adding a securitycontrol object to the list. The methods aList.add( ), aList.getFirst( ),and aList.getNext( ) are member methods in a list object thateffectively operate a list object as an iterator. An ‘iterator’ is aconventional object oriented design pattern that supports sequentialcalls to elements of an aggregate object without exposing underlyingrepresentation. In this example, main( ) assumes that aList.getNext( )returns null upon reaching the end of the list. It is common also, forexample, for list classes to support a separate member method called,for example, ‘is Done( ),’ to indicate the end of a list. Any indicationof the end of a list as will occur to those of skill in the art is wellwithin the scope of the present invention.

In addition, the exemplary pseudocode security class includes a membermethod, main( ), that validates security access data in turn for eachsecurity control object in the list. In this particular example, thevalidation method is called ‘main( )’ to support implementing securityobjects in Java, so that the validation method can be called by a callto the object name itself. On the other hand, when SecurityClass isimplemented as a Java servlet, there is no requirement for a membermethod named ‘main( ),’ because, although servlets also are invoked byuse of the class name itself, the interior interface requirements forservlets are different. When SecurityClass is implemented as a Javaservlet, therefore, the name of the member method ‘main( )’ is changedto implement a member method signature from the standard Java servletinterface, such as, for example:

-   -   public void service(ServletRequest req, ServletResponse res).

The validation method main( ) operates by obtaining from the list eachsecurity control object in turn and calling in each security controlobject the interface member method ‘validate( ).’ As described in detailabove, the validate( ) method in each security control object promptsfor security access data, compares security access data to securitycontrol data, and return true or false according to whether thecomparison succeeds or fails. SecurityClass.main( ) operates by denyingaccess and returning false if validation fails for any security controlobject in the list. SecurityClass.main( ) grants access and return trueif validation succeeds for all security control objects in the list.

If SecurityClass.main( ) grants access, the access granted has theauthorization level set by the member method setAuthorizationLevel( ).More particularly, in the method of FIG. 2, determining (220) access(222) includes authorizing a level of access in dependence upon theauthorization level of access for the resource (314 on FIG. 3). In theexample of security objects implemented to accept calls from hyperlinksin web pages displayed in browsers on client devices located remotelyacross a network, the security objects themselves often are implementedas servlets or CGI programs that administer HTTP GET and PUT requestmessages. In such exemplary embodiments, a security object grantingaccess to a resource having only ‘read’ authorization level would honora GET request by transmitting to the client browser a copy of theresource in HTML. The same exemplary security object, however, would nothonor a PUT request for writing data to the resource.

FIG. 4 sets forth a class relations diagram summarizing exemplaryrelations among classes and objects useful in various embodiments of thepresent invention. As shown in FIG. 4, in many embodiments, concretessecurity classes (108), from which security objects are instantiated,are subclasses that inherit from abstract security classes (402).Similarly, concrete security control classes (316), from which securitycontrol objects are instantiated, are subclasses that inherit fromabstract security control classes (404).

In addition, it is useful to remember that ‘abstract,’ as the term isused here to describe classes, is used in support of interfacedefinition, in a fashion similar to its use in the terminology of C++.In Java, structures that here are called abstract classes would becalled ‘interfaces,’ as such. No doubt such structures have other namesin other environments, but here they are called ‘abstract classes’ andused to illustrate declarations of object oriented interfaces.

Foundries (224) are shown in FIG. 4 as classes having references tofactory classes (406) and concrete security classes (108). Foundries(224), as described in detail above, cooperate with factories (406) andsecurity objects instantiated from concrete security classes (316) bypassing to security objects references to security control objects forinclusion in security control object lists (318). The arrow (412) can bedrawn between security classes (108) and security control classes (316),indicating that a security class ‘has a’ security control class, becausethe reference needed to implement the object oriented ‘has a’relationship is provided to the security class by a foundry (224) forstorage in a security control object list (318).

Security control object lists (318) are often implemented as containerobjects from a standard library in, for example, C++ or Java. That is, asecurity control object list (318) is typically a class objectaggregated by reference to a security object instantiated from asecurity class (108). With member methods (410) such as add( ),getFirst( ), and getNext( ), a security control object list (318) oftencan function as a so called ‘iterator,’ greatly easing manipulation ofsecurity control objects on behalf of a security object. Iteratoroperations are illustrated in the pseudocode above for SecurityClass.

Again referring to FIG. 2, the illustrated method includes deploying(226) a security object. Security objects can be created (206) on aclient device and deployed (226) to a client device (102), including thesame client device on which the security object is created, or to aserver (106). Security objects can be created (206) on a server anddeployed (226) to a server (106), including the same server on which thesecurity object is created, or to a client device (102). Deployment canbe local, that is, within the same client device or server, or within atrusted LAN.

Deployment can be remote, that is, across public networks, such as, forexample, the Internet or the World Wide Web. One advantageous mode ofremote deployment, for example, is a download of a security objectimplemented as a Java applet to a Java-enabled web browser. An applet isa Java program designed to be run from another program, such as abrowser, rather than directly from an operating system. Because appletstypically are small in file size, cross-platform compatible, and highlysecure (can't be used to access users' hard drives), they are useful forsmall Internet applications accessible from a browser, including, forexample, security objects according to the present invention.

More particularly, in some embodiments according to the method of FIG.2, a resource (112) resides on a resource server (110), and the methodincludes deploying (226) the security object (108) on a security server(106) and receiving (208) the request for access to the resource in asecurity server (106) from a client device (102) across a network (202).Network (202), as mentioned above, can be any network, public orprivate, local area or wide area, wireless or wired. In embodimentsaccording to this aspect of the invention, receiving (208) a request foraccess (210) is typically carried out through some form of remoteprocedure call, such as, for example, a hyperlink to a Java servlet, ahyperlink to a CGI function, a call to a member method in a CORBAobject, a remote object call through a Java RMI interface, or a remoteobject call through a DCOM interface.

In a further aspect of the method of FIG. 2, a resource (112) resides ona client device (102), and the client device has an application program(120 on FIG. 1 c) that accesses the resource. In this kind ofembodiment, the method includes deploying (226) the security object(108) on the client device (102), effecting an architecture like the oneshown in FIG. 1 c. In this configuration, receiving (208) a request(210) for access to the resource (112) includes receiving (208) therequest for access to the resource in the security object itself as acall to the security method (218). In some embodiments of this kind, infact, a security object (108) can be compiled right into the clientapplication (120), so that receiving a request for access is implementedas a conventional local function call, with no particular need forremote procedure calling methodologies such as those listedabove—hyperlinks, CORBA, Java RMI, and so on.

In some embodiments of the present invention receiving (208) a requestfor access (210) to a resource (112) comprises a call to a securitymethod (218) in a security object (108). Such direct calls can beimplemented through Java, for example, by naming the security method(218) ‘main( )’ and issuing a call of the form ‘javaSecurityObjectName.’ Alternatively, a call may be issued from ahyperlink in a browser to a security method in a security objectimplemented as a Java servlet by including in an HTTP request message aURI of the form:

-   -   http://ServerName/servlet/MySecurityObject        where MySecurityObject is the name of a security object        implemented as a servlet and containing a security method named        according to the conventions of the standard Java servlet        interface, that is, for example, named ‘service( ).’

FIG. 5 sets forth a data flow diagram illustrating more detailedembodiments of receiving (208) a request (210) for access to a resource.In one method according to FIG. 5, receiving (208) a request (210) foraccess to a resource (112) includes identifying (502) a security object(108), that is, identifying a security object that controls access tothe resource. Consider the example mentioned earlier of a securityobject (108) implemented as a Java servlet. In such an exemplaryembodiment, identifying (502) the security object (108) comprisesidentifying the security object in dependence upon a URI (508).Typically, the URI (508) originates from a hyperlink (506) in a web page(504) in a communications application (104) in a client device (102).The communications application can be, for example, a browser in aclient device that is a personal computer or a microbrowser in a clientdevice that is a web-enabled cell phone. Such embodiments typicallycommunicate the identification of the security object in the form of anHTTP request message containing the URI. The URI can have this form:

-   -   http://ServerName/servlet/MySecurityObject        from which a servlet-enabled server can invoke the security        object as a servlet named MySecurityObject. The server does not        invoke the security object in the sense of calling it as such.        The server ‘invokes’ the security object in that the server        calls a member method within the security object according to        the conventions of the standard Java servlet interface. In this        example, the identity of the security object was known to the        calling application.

It is possible, however, that the calling application may know theidentity of a resource without knowing the identity of the securityobject that controls access to the resource. In such an exemplaryembodiment, a request for access to a secured resource may arrive in anHTTP request directed at a resource that is a document identified as:

-   -   http://ServerName/SomeoneElse'sFiles/Document123.

For use in such embodiments, in one method according to FIG. 5,identifying (502) the security object (108) includes identifying thesecurity object in dependence upon a URI (508) that identifies theresource (112), including finding (516), in dependence upon the URI(508) identifying the resource (112), an identification (514) of thesecurity object in an access control table (512).

Although in this example, where the access request came with a URI, theidentification (312) of the resource is, for example, a URI or afilename or pathname extracted from a URI. In embodiments of theinvention generally, there is no requirement that the communicationsapplication be a browser or use HTTP for its communications. Theresource identification (312) can be any digital identification,including for example, a filename or pathname communicated in aplaintext string or in cyphertext.

-   -   DO GLOBAL ON ‘IDENTIFIER . . . ’

The identification (514) of the security object can be the securityobject name, for example, or, in the example where the security objectis implemented as a Java servlet, the identification (514) of thesecurity object can be a URI in the now familiar form:

-   -   http://ServerName/servlet/MySecurityObject.

In this kind of embodiment, a security server is programmed uponreceiving a request for access, to check an access control table (512).In fact, this small change in the overall programming of the securityserver, is the only thing that makes it a ‘security server’ within themeaning of the present invention. The security server needs no othersecurity-related service upon it. Security authentication andauthorization are handled by the security object. All the securityserver needs to do is look up the identity of the security object andinvoke it. ‘Invoke’ in this sense means to call the security method inthe security object by, for example, a call to ‘java SecurityObjectName’for a security object implemented as a standard Java class, a call to‘http://ServerName/servlet/MySecurityObject’ for a security objectimplemented as a Java servlet, or a call to ‘SecurityObjectName’ for asecurity object implemented as a C++ program. If the security server canfind no security object for the resource identified in a request foraccess, then the security server continues its normal operations. If thesecurity server is programmed to grant access only upon finding acorresponding security object, then the security server denies accesswhen no such object is found in the access control table. If thesecurity server has other security services available upon it, then itis often programmed to apply them in its usual fashion.

Alternatively, if the security server has no other security servicesavailable upon it, it may be programmed to comply with HTTP requestmessages on their own terms according to whether they are GET messages,PUT messages, and so on. In other words, the security server canimplement the standard operations of a web server. This implementationis a little riskier than the other two examples mentioned just above butit has the advantage of being very easy to implement, requiring as itdoes only one small change to the source code of a conventional webserver just to do one lookup in an access control table and, if thelookup succeeds, invoke a security object identified in the lookup.

By this point in this disclosure, several advantages of using variousembodiments of the present invention are clear. One advantage is pureflexibility, especially at the user level and the application level.Embodiments of the present invention can make foundry applicationsavailable to ordinary users, rather then just to system administrators.Any user can choose to associate with any resource any kind of securitydata supported in a security system. Users can decide for themselveswhether they want just a plain text logon ID and/or something much moreelaborate—a fingerprint, a voiceprint, a retinal scan, and so on. As aresult, users can be given great freedom in defining the securitycontent and security level for securing users' resources, much greaterfreedom than available to users in prior art systems.

Another advantage of security objects according to the present inventionis that security servers, communications servers, resource servers suchas document or application servers—none of the servers in networks needto have any particular concern with security beyond associating asecurity object with a resource. Moreover, as mentioned above, it ispossible within the present invention to establish a regime in which allresources in a particular location are accessed only indirectly throughsecurity objects, in which case, a server providing access to suchresources need have upon it no other security service whatsoever, atleast as regards authentication and authority level. In particular,servers that administer access to resources need not be concerned withthe type of security data provided by users or required to qualify foraccess to a resource.

Another advantage of the present invention relates to encryption. Asdescribed above, certain elements of security control data areadvantageously stored in encrypted form. Persons seeking unauthorizedaccess to resources may seek to decrypt such security control data. Suchunauthorized access is made much more difficult by a need, easilyestablished by any properly authorized user, to decrypt not only asingle security control data element such as a password, but also todecrypt multiple security control data elements including fingerprints,retinal scans, voiceprints, and so on.

Another advantage of the present invention is the ease with which a usercan arrange multiple access authorization for multiple users. A userauthorized to do so, under the present invention, can simply createmultiple security objects for a single resource and distribute, forexample, a URI identifying each such separate security object toseparate users. By such usage, a user can quickly grant with respect toa particular document, for example, ‘read’ access to Jane Smith, ‘read’access to Joe Blow, ‘write’ access to Mike Walker, and reserve ‘execute’access to the original user, the owner of the document. The securitycontrol data can be set differently in each of the separate securityobjects all of which point to the same document, therefore preventingJane and Joe from using Mike's security object to gain access, even ifthey can gain access to Mike's security object.

Another advantage is reduction of security responsibility on the part ofserver system administrators. This advantage obtains because securityobjects of the present invention tend to upcast security control fromcommunications protocols layers to application layers. “Layers” in thiscontext refers to the standard data communications protocol stack inwhich the IP protocol resides in layer 3, the so called ‘network layer,’and the Transmission Control Protocol, or “tcp,” resides in layer 4, theso called transport layer. In this context, SSL is considered a layer 4security protocol, and the well known protocol for virtual privatenetworking known as “IPSec” is considered a layer 3 protocol. In thisdisclosure, any functionality above layer 4 is described as residing inan ‘application layer.’ Therefore security objects according to thepresent invention are considered to be application layer software. Assuch, security objects and their operations in securing access toresources are completely transparent to systems administrators workingon layer 4 or layer 3 security systems. In fact, it is possible tostructure web servers as security servers, as mentioned above, so thatsuch security servers have little or no concern regarding whether layer4 or layer 3 security systems even exist at all. This is potentially adramatic shift in security responsibilities for system administrators,including, for example, system administrators in Internet ServiceProviders or ‘ISPs.’

It will be understood from the foregoing description that variousmodifications and changes may be made, and in fact will be made, in theexemplary embodiments of the present invention without departing fromits true spirit. The descriptions in this specification are for purposesof illustration only and are not to be construed in a limiting sense.The scope of the present invention is limited only by the language ofthe following claims.

1. A method of controlling access to a resource, the method comprising:creating a security object in dependence upon user-selected securitycontrol data types, the security object comprising security control dataand at least one security method receiving a request for access to theresource; receiving security request data; and determining access to theresource in dependence upon the security control data and the securityrequest data.
 2. The method of claim 1 wherein creating a securityobject further comprises: storing in the security object a resourceidentification for the resource; storing in the security object anauthorization level of access for the resource; storing in the securityobject user-selected security control data types; and storing, in thesecurity object, security control data for each user-selected securitycontrol data type.
 3. The method of claim 2 wherein determining accessincludes authorizing a level of access in dependence upon theauthorization level of access for the resource.
 4. The method of claim 1further comprising deploying the security object.
 5. The method of claim1 further comprising deploying the security object on a client device.6. The method of claim 1 wherein the resource is located on a securityserver.
 7. The method of claim 1 wherein the resource is located on aclient device.
 8. The method of claim 1 wherein: the resource resides ona client device, the client device having an application program, themethod further comprises deploying the security object on the clientdevice, and receiving a request for access to the resource furthercomprises receiving, in the security object itself, the request foraccess to the resource as a call to the security method.
 9. The methodof claim 1 wherein receiving a request for access to the resourcecomprises calling the security method.
 10. The method of claim 1 whereinreceiving a request for access to the resource further comprisesidentifying the security object.
 11. The method of claim 10 whereinidentifying the security object comprises identifying the securityobject in dependence upon a URI.
 12. The method of claim 11 whereinidentifying the security object comprises identifying the securityobject in dependence upon a URI that identifies the resource, includingfinding, in dependence upon the URI identifying the resource, anidentification of the security object in an access control table.
 13. Asystem for controlling access to a resource, the system comprising:means for creating a security object in dependence upon user-selectedsecurity control data types, the security object comprising securitycontrol data and at least one security method; means for receiving arequest for access to the resource; means for receiving security requestdata; and means for determining access to the resource in dependenceupon the security control data and the security request data.
 14. Thesystem of claim 13 wherein means for creating a security object furthercomprises: means for storing in the security object a resourceidentification for the resource; means for storing in the securityobject an authorization level of access for the resource; means forstoring in the security object user-selected security control datatypes; and means for storing in the security object security controldata for each user-selected security control data type.
 15. The systemof claim 15 wherein means for determining access includes means forauthorizing a level of access in dependence upon the authorization levelof access for the resource.
 16. The system of claim 13 furthercomprising means for deploying the security object.
 17. The system ofclaim 13 further comprising means for deploying the security object on asecurity server.
 18. The system of claim 13 further comprising means fordeploying the security object on a client device.
 19. The system ofclaim 13 wherein the resource is located on a security server.
 20. Thesystem of claim 13 wherein the resource is located on a client device.21. The system of claim 13 wherein: the resource resides on a clientdevice, the client device having an application program, the systemfurther comprises means for deploying the security object on the clientdevice, and means for receiving a request for access to the resourcefurther comprises means for receiving, in the security object itself,the request for access to the resource as a call to the security method.22. The system of claim 13 wherein means for receiving a request foraccess to the resource comprises means for calling the security method.23. The system of claim 13 wherein means for receiving a request foraccess to the resource further comprises means for identifying thesecurity object.
 24. The system of claim 23 wherein means foridentifying the security object comprises means for identifying thesecurity object in dependence upon a URI.
 25. The method of claim 24wherein means for identifying the security object comprises means foridentifying the security object in dependence upon a URI that identifiesthe resource, including means for finding, in dependence upon the URIidentifying the resource, an identification of the security object in anaccess control table.
 26. A computer program product for controllingaccess to a resource, the computer program product comprising: arecording medium; means, recorded on the recording medium, for creatinga security object in dependence upon user-selected security control datatypes, the security object comprising security control data and at leastone security; means, recorded on the recording medium, for receiving arequest for access to the resource; means, recorded on the recordingmedium, for receiving security request data; and means, recorded on therecording medium, for determining access to the resource in dependenceupon the security control data and the security request data.
 27. Thecomputer program product of claim 26 wherein means for creating asecurity object further comprises: means, recorded on the recordingmedium, for storing in the security object a resource identification forthe resource; means, recorded on the recording medium, for storing inthe security object an authorization level of access for the resource;means, recorded on the recording medium, for storing in the securityobject user-selected security control data types; and means, recorded onthe recording medium, for storing in the security object securitycontrol data for each user-selected security control data type.
 28. Thecomputer program product of claim 26 wherein means for determiningaccess includes means, recorded on the recording medium, for authorizinga level of access in dependence upon the authorization level of accessfor the resource.
 29. The computer program product of claim 26 furthercomprising means, recorded on the recording medium, for deploying thesecurity object.
 30. The computer program product of claim 26 furthercomprising means, recorded on the recording medium, for deploying thesecurity object on a client device.
 31. The computer program product ofclaim 26 wherein the resource is located on a security server.
 32. Thecomputer program product of claim 26 wherein the resource is located ona client device.
 33. The computer program product of claim 26 wherein:the resource resides on a client device, the client device having anapplication program, the system further comprises means, recorded on therecording medium, for deploying the security object on the clientdevice, and means for receiving a request for access to the resourcefurther comprises means, recorded on the recording medium, forreceiving, in the security object itself, the request for access to theresource as a call to the security method.
 34. The computer programproduct of claim 26 wherein means for receiving a request for access tothe resource comprises means, recorded on the recording medium, forcalling the security method.
 35. The computer program product of claim26 wherein means for receiving a request for access to the resourcefurther comprises means, recorded on the recording medium, foridentifying the security object.
 36. The computer program product ofclaim 35 wherein means for identifying the security object comprisesmeans, recorded on the recording medium, for identifying the securityobject in dependence upon a URI.
 37. The computer program product ofclaim 36 wherein means for identifying the security object comprisesmeans, recorded on the recording medium, for identifying the securityobject in dependence upon a URI that identifies the resource, includingmeans, recorded on the recording medium, for finding, in dependence uponthe URI identifying the resource, an identification of the securityobject in an access control table.